The proliferation of the Internet has resulted in a thriving electronic commerce industry, where more and more products and services are available to consumers in a variety of non-traditional ways, e.g., internet, telephone sales, wireless, interactive TV, etc. For example, in traditional online consumer-merchant transactions, consumers typically provide merchants with transaction numbers (e.g, charge card numbers) from their existing debit, phone, credit or other transaction/service cards (e.g., American Express®, VISA®, MasterCard® and Discover Card®, AT&T®), MCI®), etc.). Transmission of transaction numbers via these traditional means has created increased opportunities for fraud. Namely, it is possible for these numbers to be intercepted during transmission, after transmission, while being stored electronically or at the merchant's online or offline location. In light of the increase in charge card fraud involving situations where the physical charge card is not actually presented to the merchant, consumers are becoming increasingly cautious and leery of giving out their actual charge card number to merchants (or other unknown third parties asserting to be merchants).
In traditional online purchases, a consumer often browses the Internet for items to purchase. When the consumer finds an item that he or she is interested in purchasing, the consumer typically selects an item to add to a virtual shopping cart. When the consumer has finished shopping, and desires to purchase an item, the consumer usually proceeds to a virtual checkout, where the consumer is prompted for payment and delivery information. The consumer then typically is required to enter the appropriate delivery and credit card information, where the the consumer reads the credit card number directly from the consumer's physical credit card. This information is then transmitted electronically to the merchant via a public internet network. Although the transmission is often encrypted, there exists the possibility that the number will be intercepted en route to the merchant. More likely, however, is that the number will be fraudulently used by an unscrupulous third party, such as a dishonest employee of the merchant.
In addition to the previous example, various other means of credit card skimming are common in the industry. In an attempt to minimize these and similar problems relating to credit card fraud, banks and other credit card institutions have begun to explore various ways to provide customers with temporary transaction numbers to facilitate online transactions, where the actual credit card is not disclosed to the merchant or any other third party.
For example, U.S. Pat. No. 5,883,810 issued to Franklin, et al., which is hereby incorporated by reference, discloses a system to facilitate online commerce where a customer is able to register and sign-up for an “online commerce card.” This online commerce card does not exist in physical form, but instead exists in a digital form that can be electronically configured for online commerce. The issuing bank issues the digital card to the customer in the form of a signed digital certificate binding the customer to the bank and provides the customer a software module that can be invoked when using the commerce card to conduct an online transaction. This online commerce card is assigned a permanent customer account number that resides with the issuing bank and is not given to the customer. In Franklin, when a customer desires to make an online purchase, the customer requests from the bank a transaction number that is good for a single transaction and with a limited life. This single transaction number is provided to a merchant to complete a purchase and is then processed by the merchant for authorization and settlement, with the issuing bank substituting and re-substituting the single transaction number and the customer account number as necessary in order to insure that the actual account number is not released to any third party.
Although the single use transaction number disclosed by Franklin provided some improvement over the traditional online transaction methods, several problems remained. For example, Franklin's system, which requires the generation of a digitally keyed online commerce card that does not exist in the physical form, requires customers to register and use an assigned digital certificate. Furthermore, this system requires the customer to download modules to facilitate the registration and transaction processes. Although Franklin notes that the commerce card is configured to be used by the customer in one or more areas of commerce in which the customer typically employs a charge card, Franklin fails to disclose how a consumer's existing plastic credit card number could be used to facilitate transactions. Specifically, Franklin requires instead, for the cardholder to sign-up and register in advance for an online commerce card that is not the cardholder's existing physical credit card, but is a non-physical digital card. Furthermore, the Franklin single transaction number will not work for multiple payment arrangements, i.e., where there is one purchase but multiple payment components.
Additional publications also disclose efforts to make transactions more secure, such as, for example, PCT Application, WO 99\49424, published on Sep. 30, 1999, and PCT Application WO 99\49586, published on Aug. 24, 2000 (collectively “Orbis”), hereby incorporated by reference, which attempt to expand and improve on the use of temporary transaction numbers. Specifically, Orbis discloses the use of a limited use credit card number that is associated with a master credit card (e.g., a physical credit card).
Orbis discloses using this limited use credit card number for transactions with merchants so that the physical credit card is not disclosed to the merchant or other third parties. In Orbis, for example, the bank or credit card provider issues the cardholder a non-activated limited use credit card number that is associated with the cardholder's master credit card. In an online transaction, the cardholder activates the limited use credit card and provides that number to the merchant to complete a transaction. On presentment to the card provider for authorization, the card provider verifies, inter alia, that the conditions of use have been met. If the conditions have been met, the card provider provides the merchant with an approval code that will accompany the payment request during settlement. If, however, during the authorization process, it is determined that certain conditions of use have not been met, the card provider de-activates the limited-use card. With the limited-use credit card de-activated, the merchant will not be paid and the transaction is not able to proceed through settlement. Conversely, if the limited use number is not submitted at all for authorization, and the merchant chooses to process this transaction for settlement, settlement may later occur and the merchant may be paid, with the incumbent risk to the merchant, however, that charge-back is likely if the charge is later disputed by the cardholder.
In prior art systems, if a transaction involving a temporary number is not authorized for failing to meet certain limited-use conditions, the number is deactivated and will not be processed through settlement. In real world environments, this creates certain problems. For instance, many online or telephonic purchases are multiple payment purchases, where one product may be purchased but multiple periodic payments are used to complete the transaction. Although the consumer is usually provided with the product up front, there may be occasions where the product is not delivered until all payments have been completed. The prior art systems occasionally create situations where the temporary transaction number is deactivated at some point in the multiple payment process where the merchant is not fully paid, possibly resulting in the product not being delivered to the consumer.
As previously noted, prior art systems typically use the authorization process to determine whether limited-use conditions are satisfied. The resultant comparison utilized in the authorization process is then used to update a conditions database. However, the consumer rarely knows exactly how many authorization requests will be submitted by the merchant. For example, a consumer may purchase an item online for $1000, agreeing to apply ten monthly $100 payments to complete the purchase. Initially, one employing a prior art system may think to apply a number of different limited use conditions to facilitate this transaction, e.g., one transaction for $1000, ten transactions for $100, or any combination. Additionally, different merchants may handle authorization requests in a number of different ways. A merchant may send to the card provider (i) only one authorization request for $1000; (ii) one authorization request for $1000, followed by subsequent authorization requests for each $100 payment; (iii) one authorization request for each $100 payment, or (iv) only a few periodic authorization requests. It is also common in the industry for merchants to submit pre-authorization requests followed by a subsequent request for authorization. In sum, it can be difficult for the consumer to guess exactly what method will be employed by the merchant to facilitate the authorization process.
As such, the prior art systems create situations where a temporary transaction number may be inadvertently deactivated prior to completion of the periodic payments. If, for example, the consumer only authorized one transaction, the card would be deactivated where the merchant submits one pre-authorization request, followed by a second authorization request prior to the first payment.